Hello Scawen,
much to my regret you have removed the NumPlayers and FirstPly from the MCI packet some time ago. Now it is hard to detect if I have received a complete set of MCI packets. For instance if there are exactly 16 or 24 players in list, I would not know what is the first and what is the last MCI packet, all packets contain 8 valid CompCar structs.
Is there any chance to get this information back?
kind regards
Sören
much to my regret you have removed the NumPlayers and FirstPly from the MCI packet some time ago. Now it is hard to detect if I have received a complete set of MCI packets. For instance if there are exactly 16 or 24 players in list, I would not know what is the first and what is the last MCI packet, all packets contain 8 valid CompCar structs.
Is there any chance to get this information back?
kind regards
Sören
no, unfortunately not. Shortly before Scawen started to redesign the insim interface, I have started to rewrite the internal structure of my application to get a clean separation between the GUI and the insim part of the software. This is really necessary for some features I am going to implement in the future. Due to this situation the current state of my source code is very unstable and nonworking in most cases. So I have to finish this task before I can continue to implement the new insim interface.
Nevertheless there is a chance that you can use the old version also with patch X
regards
Sören
there are PTH files for autocross layouts available already, no need to create your own PTH files. You can download all PTH files from http://www.liveforspeed.net/?page=coderfiles. I have not included these PTH files because I am not sure how TV director behaves on autocross layouts.
regards
Sören
Nevertheless it is a nice idea. But more the other way round. As an example suppose someone is writing a spectator tool in the future to watch replays. With such a relay you could also watch your old replays with older LFS versions with v3 Insim.
I have started a project with such a gateway, look here: http://www.lfsforum.net/showthread.php?t=25925
regards
Sören
Last edited by Soeren Scharf, .
this is excatly, what I am asking for
I totally agree with you, putting milliseconds into a double word is sufficient for 49 days until overflow. And we could do maths with it. So if you do not deal with MSHT internally, then change to milliseconds, in other words: as a programmer I would just use, what I use internally and copy it into the packet (for other readers: this is an opinion, not a request). But there might be a lot of insim developers now crying, so the decision is yours.
regards
Sören
In principle you are right. And I agree that Scawen should not waste time by implementing things that we can calculate ourself. And I would calculate absolute time myself if I could but I can't. So an exact explanation only for you:
- to calculate gap times you need absolute times.
- to calculate absolute times you need to add up all past laps.
- to add all past laps you are required to be connected at the start of the race
- if a spectator tool (eg. LfS TV director) connects during the middle of the race, it has missed all past laps and therefore no chance to calculate the absolute time.
Maybe I have missed a differnent way how to do this, but if you know it better, then kindly please tell me instead of just calling me lazy. Also I have not asked Scawen to implement gap calculation. Read my post again and think before you write, but never call me lazy.
you mean the arrival time of the MCI packet? Well, indeed a very exact calculation.
regards
hello Scawen,
would it be possible to include the absolute time into the LAP/SPX packets? If a program wants to calculate the gap between 2 cars, it would have to add up the times of all driven laps. But this is not possible if the program is missing the start of the race (eg. if a spectator connected to the server after some laps).
regards Sören
would it be possible to include the absolute time into the LAP/SPX packets? If a program wants to calculate the gap between 2 cars, it would have to add up the times of all driven laps. But this is not possible if the program is missing the start of the race (eg. if a spectator connected to the server after some laps).
regards Sören
some comments to the suggestion of wheel4hummer.
1) We would have to make a decision if:
So if the application calls the IDirect3DDevice8::Present function of Proxy dll 1, then this dll will call the IDirect3DDevice8::Present functions of Proxy dll 3, 4 and 5. Every of these dlls will paint some stuff and then call the original IDirect3DDevice8::Present function of the system. You see: every call of the IDirect3DDevice8::Present function from the application will result in 3 calls of the original IDirect3DDevice8::Present function. Therefore the the proxy dlls would require code changes.
3) I do not see the point with more than one proxy dll. In most cases LFS addons are insim addons. Since there is only one insim application possible at one moment, only one insim application could be active anyway.
kind regards
Sören
1) We would have to make a decision if:
- we want compatibility, so all existing proxy dlls remain working without code changes, or
- we want to load more than one proxy dll, this will of course require code changes
Proxy dll 1
/ | \
/ | \
Proxy dll 3 | \
/ | Proxy dll 5
/ Proxy dll 4 \
D3D8.dll | \
| D3D8.dll
D3D8.dllSo if the application calls the IDirect3DDevice8::Present function of Proxy dll 1, then this dll will call the IDirect3DDevice8::Present functions of Proxy dll 3, 4 and 5. Every of these dlls will paint some stuff and then call the original IDirect3DDevice8::Present function of the system. You see: every call of the IDirect3DDevice8::Present function from the application will result in 3 calls of the original IDirect3DDevice8::Present function. Therefore the the proxy dlls would require code changes.
3) I do not see the point with more than one proxy dll. In most cases LFS addons are insim addons. Since there is only one insim application possible at one moment, only one insim application could be active anyway.
kind regards
Sören
I have requested the NPL packets from the replay and additionally I did some research in single player modus.
Indeed if playing in single player the Uid of the players car is zero. Maybe this is also true for hosts in multiplayer, I have not tested it.
But in this case it was not the host, it was a player with Uid=37, who was in the players list but nowhere on the track.
I have tested in single player (and additinal 2 AI cars) and checked for contents of MCI packets. As soon as I entered the BOX (not the pit lane, I mean the setup screen), the contents of the CompCar struct was set to zero completely. It was the same behaviour as in the multiplayer replay. So I have to assume that one player (with uid=37) was in the setup screen when the race started.
It was just a bit confusing for me that I get a CompCar for a player, who is not on the track. But I have noticed it, and also the insim.txt tells that pitting players (PLP) are still in the players list (btw: I never got a PLP because the driver was already in the setup screen at start of the race).
The oddity with this is, that I get all values in the CompCar struct set to zero (also the uid) for a player with a uid of 37.
Nevertheless there is still one question: Would part of the CompCar struct can I use to detect if a driver is on track or in the pit screen? Using uid would not be possible because this can be zero for single player. But maybe checking the lapnumber for zero? As far as I know the lapnumber starts counting from 1.
Regards
Sören
Indeed if playing in single player the Uid of the players car is zero. Maybe this is also true for hosts in multiplayer, I have not tested it.
But in this case it was not the host, it was a player with Uid=37, who was in the players list but nowhere on the track.
I have tested in single player (and additinal 2 AI cars) and checked for contents of MCI packets. As soon as I entered the BOX (not the pit lane, I mean the setup screen), the contents of the CompCar struct was set to zero completely. It was the same behaviour as in the multiplayer replay. So I have to assume that one player (with uid=37) was in the setup screen when the race started.
It was just a bit confusing for me that I get a CompCar for a player, who is not on the track. But I have noticed it, and also the insim.txt tells that pitting players (PLP) are still in the players list (btw: I never got a PLP because the driver was already in the setup screen at start of the race).
The oddity with this is, that I get all values in the CompCar struct set to zero (also the uid) for a player with a uid of 37.
Nevertheless there is still one question: Would part of the CompCar struct can I use to detect if a driver is on track or in the pit screen? Using uid would not be possible because this can be zero for single player. But maybe checking the lapnumber for zero? As far as I know the lapnumber starts counting from 1.
Regards
Sören
no idea? nobody who could help?
maybe there is a driver sitting in the box (setup screen)? But I could not associate it in this case because UniqueID is also zero. So other question: is a value of zero a valid UniqueID?
regards
Sören
maybe there is a driver sitting in the box (setup screen)? But I could not associate it in this case because UniqueID is also zero. So other question: is a value of zero a valid UniqueID?
regards
Sören
I have updated the attachment in the first post, and hopefully the crashes as told by different people are gone.
@Stuff: look at mikoweb.eu, there is a tutorial and some source to start with. Also look for the Drift Gauge and G-Meter, Racer_S2 has uploaded the sources for his tool too.
@Dygear: what are FOM overlays?
regards
Sören
@Stuff: look at mikoweb.eu, there is a tutorial and some source to start with. Also look for the Drift Gauge and G-Meter, Racer_S2 has uploaded the sources for his tool too.
@Dygear: what are FOM overlays?
regards
Sören
See there, an easteregg :) [Update]
I just "found" this at the weekend, so I wanted to show 
Download and put the files into the LFS folder. Then start LFS and watch.
Do NOT put these files into the Windows system directory!!!
regards
Sören
Download and put the files into the LFS folder. Then start LFS and watch.
Do NOT put these files into the Windows system directory!!!
regards
Sören
Last edited by Soeren Scharf, .
Reason : updated the attachment because of crashes
here is the first draft of the source code and a compiled version in the attachment for testing purposes. I have for now implemented the ini file option.
BTW: I must admit, that in opposit to this my first idea was much more complicated. I thougth about an approach, where custom Dlls could be loaded and unloaded at runtime.
The source of the current solution is quite small and simple. There is only one unpleasant issue still there, I have also seen this in the source of Drift Gauge and in the tutorial sources from mikoweb. So I have to assume more dlls derived from this will have this issue too. Me must not call FreeLibrary inside the DllMain function (the MSDN says so). But for now it works. Nevertheless I would like to know where would be the appropriate location to call FreeLibrary, maybe in the Release function of the D3D8 interface?
@DragonCommando: Turbo Pascal, jeah, good language with a rigorous syntax check, very good to avoid a lot of unnecessary bugs. I loved this language, but it is a long time ago, that I have used it.
Oh, and believe: the attached dll will work with every addon D3D8.dll, they do not need to be recompiled. I have tested this with one of my own modded D3D8 wrapper Dlls.
regards
Sören
BTW: I must admit, that in opposit to this my first idea was much more complicated. I thougth about an approach, where custom Dlls could be loaded and unloaded at runtime.
The source of the current solution is quite small and simple. There is only one unpleasant issue still there, I have also seen this in the source of Drift Gauge and in the tutorial sources from mikoweb. So I have to assume more dlls derived from this will have this issue too. Me must not call FreeLibrary inside the DllMain function (the MSDN says so). But for now it works. Nevertheless I would like to know where would be the appropriate location to call FreeLibrary, maybe in the Release function of the D3D8 interface?
@DragonCommando: Turbo Pascal, jeah, good language with a rigorous syntax check, very good to avoid a lot of unnecessary bugs. I loved this language, but it is a long time ago, that I have used it.
Oh, and believe: the attached dll will work with every addon D3D8.dll, they do not need to be recompiled. I have tested this with one of my own modded D3D8 wrapper Dlls.
regards
Sören
#include <windows.h>
// we do not take care of the type of the pointer
#define IDirect3D8 void
HINSTANCE g_hNextDll;
void LoadNextDll(void);
BOOL APIENTRY DllMain(HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
g_hNextDll = NULL;
break;
case DLL_PROCESS_DETACH:
if (g_hNextDll)
{
FreeLibrary(g_hNextDll);
g_hNextDll = NULL;
}
break;
}
return TRUE;
}
// Exported function (export declared in the .def file)
IDirect3D8* WINAPI Direct3DCreate8(UINT SDKVersion)
{
if (!g_hNextDll) LoadNextDll();
// Hooking IDirect3D Object from Original Library
typedef IDirect3D8 *(WINAPI* D3D8_Type)(UINT SDKVersion);
D3D8_Type D3DCreate8_fn = (D3D8_Type)GetProcAddress(g_hNextDll, "Direct3DCreate8");
if (!D3DCreate8_fn)
{
ExitProcess(0); // exit the hard way
}
return D3DCreate8_fn(SDKVersion);
}
void LoadNextDll(void)
{
char path2dll[MAX_PATH];
char path2ini[MAX_PATH];
if (GetModuleFileName(NULL, path2ini, sizeof(path2ini)))
{
// get the path of the LFS folder
while ((path2ini[strlen(path2ini) - 1] != '\\') && (strlen(path2ini) > 0))
path2ini[strlen(path2ini) - 1] = 0;
strcat(path2ini, "D3D8.ini");
GetPrivateProfileString("D3D8Wrapper", "ProxyDll", "",
path2dll, sizeof(path2dll), path2ini);
if (strlen(path2dll) > 0)
{
g_hNextDll = LoadLibrary(path2dll);
if (g_hNextDll)
return;
}
}
// no ini file there or loading the custom dll failed, so let's load the systems d3d8.dll
GetSystemDirectory(path2dll, MAX_PATH);
strcat(path2dll, "\\d3d8.dll");
g_hNextDll = LoadLibrary(path2dll);
if (!g_hNextDll)
{
ExitProcess(0); // exit the hard way
}
}
Brilliant idea, stacking has the huge advantage, that existing D3D8.dll's do not need to be modified, they just need to be renamed to a unique name. Of course we will not get a huge chain of several addons, but with one common dll and one custom dll it will do the job. (see attachment as example).
Indeed this soultion is more simple because this common proxy dll does not need to wrap the whole D3D8 interface, but only the DirectD3Create8 function, where it decides which dll to load. Also we will not loose performance.
But there is also one limitation: The addon needs to be active during startup of LFS. Once all Dlls are loaded, the 'stack' can not be modified. So loading/unloading the custom dll at runtime would not be possible. If we decide, that this is not really a handicap, then I would prefer this as the solution.
During this weekend I will prepare a source code suggestion.
this is exactly what is written above. Configuration file or whatever else to use is still subject to discuss. But I would agree that an ini file would be the most plausible decision.
kind regards
Sören
DirectX output, one common D3D8.dll for all addons (technical discussion)
hello developers,
due to several requests for DirectX output I want to initiate a project for one common D3D8.dll for all addon developers. Participants of the following discussion should have a basic understanding of the wrapper dll approach and knowledge about DirectX programming would be helpful. A tutorial of the proxy concept can be found on mikoweb.eu
Introduction
Even if the wrapper dll approach is very easy to understand and to implement, it has one significant drawback. As every addon developer will write his own D3D8.dll for his purpose and copy it into the LFS folder, it may lead in overwriting the D3D8.dll of other addons.
Objective
The goal is one common D3D8.dll for all addons. Ideally it would only do the wrapping and would not have any functionality. On request of the addon it would load an additional addon specific dll with all needed funtionality.
Problems
We need to discuss several questions:
Sören
due to several requests for DirectX output I want to initiate a project for one common D3D8.dll for all addon developers. Participants of the following discussion should have a basic understanding of the wrapper dll approach and knowledge about DirectX programming would be helpful. A tutorial of the proxy concept can be found on mikoweb.eu
Introduction
Even if the wrapper dll approach is very easy to understand and to implement, it has one significant drawback. As every addon developer will write his own D3D8.dll for his purpose and copy it into the LFS folder, it may lead in overwriting the D3D8.dll of other addons.
Objective
The goal is one common D3D8.dll for all addons. Ideally it would only do the wrapping and would not have any functionality. On request of the addon it would load an additional addon specific dll with all needed funtionality.
Problems
We need to discuss several questions:
- We need some kind of interprocess communication to instruct the D3D8.dll to load/unload the addon specific part. What kind to use (pipe, loopback, shared memory...)?
- What functions does the addon specific dll needs to export?
- How to handle a "dll only" addon (example: Drift Gauge and G-Meter by Racer_S2)? There is no 2nd process that could instruct the dll to load additional functionality.
Sören
starting this tool from the same bat file would be possible but useless as long as you need to press the "connect" button manually. So it looks like I should implement command line options too.
it will ... of course... it will ...
.... sooner or later ....
Indeed currently I am playing with 2 possible approaches to get the result,
- a wrapper/proxy dll (or tunneling as called in this thread) as described on mikoweb.eu, and
- hooking the functions directly
I have not yet decided, what approach to use. The first solution is very very easy to understand and to implement, but it has some drawbacks. The main disadvantage is, every addon developer is now writing a D3D8.dll for his purpose and copy it into the LFS folder, and therefore overwriting the D3D8.dll of others. Kegetys already used this approach, Racer_S2 with his "Drift Gauge and G-Meter" too, others (Becky, me...) might follow and complete the chaos.
I think, in the first step addon developers should come togehter an develop one unique D3D8.dll for all addons. This dll would load then an addon specific dll on demand of the addon. It is not such a huge task, so I could take the work as long as we all agree about the interfaces.
hello Becky,
thx for your answer.
No, it is not the host. In other replays I read the correct number. Also please look exactly at the screenshot, it is not just padded with zeros. It is the first of 2 MCI packets, and in this packet it is the 2nd CompCar struct of 8.
regards
Sören
wrong MCI packet data, bug?
just observed that one of the CompCar structures in a MCI packet is set to zero completely. The MCI packet tells me, that there are 12 players in race. But that is wrong, there are only 11 players. Where does the 12th player come from? Is it a player connected and spectating?
And (much more important) how can I distinguish between a valid CompCar information and such a CompCar as attached in the screenshot?
Background info:
- Version S2U
- Replay: Multiplayer (that Demo replay from my TV Director thread)
Thx and regards
And (much more important) how can I distinguish between a valid CompCar information and such a CompCar as attached in the screenshot?
Background info:
- Version S2U
- Replay: Multiplayer (that Demo replay from my TV Director thread)
Thx and regards
.7z is 7-zip, go to http://www.7-zip.org and download it, it is free to use.
I have decided to use 7-zip because it compresses much much better especially the pth files inside the archive. And the traffic for my webspace is limited, so I must not waste bytes by large zip or rar files.
Alternatively I have uploaded the tool in a zip file but without the pth files.
Adding an input field for password would not be a problem, I have made a note to do this.
Nevertheless to make streaming I would suggest to use a client connected to the server and stream from the client. Even if possible to run TVdirector and LFS on different computers, camera movement would be much smoother if both programs are running on the same computer.
Furthermore I would suppose, that performance and connection to the drivers is affected, if the server is running in graphical mode and the computer has to manage the streaming too.
In LFS type letter m into the chat after you have moved the camera to a new position, then in TVdirector uncheck the camera button in the toolbar.
kind regards
Sören
hello Racer_S2,
in your addon tool Drift Gauge and G-Meter v1.4 you are using the proxy-dll approach instead of using DETOURS. May I ask, why you did choose in this way?
Secondly, what about the performance? I have played a little with the dll from mikoweb and noticed, that LFS is doing between 2000 up to 10000 function calls into the interface every frame. Curiously I did not noticed any frame drop. How much time we are loosing by every function call into the interface (due to the fact, that now every call has to go through our proxy dll).
I am very interested in your answers.
regards
Sören
Edit: Big thx for making the source code of your addon tool public, hopefully it will help me in getting started with DirectX.
Last edited by Soeren Scharf, .
Of course you may use it... no, you must use it! If nobody is using this tool, then its not worth the work.
what do you mean with fixed positions? no change in heading and pitch?
regards
Soeren
Update, Version 0.1: see first post in this thread.
regards
regards
Why? What problem?
All you need to to is to download the appropriate GPP version from http://www.mikoweb.eu/index.php?node=28, there is a wrapper dll called d3d8.dll and a proxy dll called gpcomms.dll included. Put the d3d8.dll into the Lfs folder. Then in your application load gpcomms.dll, it is a simple Win32 dll. Load it as you would load any other dll. Inside this dll there is a function like OutputText(x,y,text) or PrintImage(x,y,filename.bmp). All your application needs to do is to call these functions and gpcomms.dll will do the job for you.
Instead of this you want to force lfs to load your own dll. You write that you don't understand anything about COM and you are confused about dll injection and hooks and ....
hmmmm .... Sorry .....
FGED GREDG RDFGDR GSFDG